
Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 


1. Thesis and Dissertation Collection, all items 


2011-09 

Establishing a product baseline for global 
positioning system satellites through 
functional and physical configuration audits 


Willcox, Travis G. 

Monterey, California. Naval Postgraduate School 


http://hdl.handle.net/10945/5527 


This publication is a work of the U.S. Government as defined in Title 17, United 
States Code, Section 101. Copyright protection is not available for this work in the 
United States. 


Downloaded from NPS Archive: Calhoun 



DUDLEY 

KNOX 

LIBRARY 


http ://w w w. nps.edu/lEbrary 


Calhoun is the Naval Postgraduate Schools public access digital repository for 
research materials and institutional publications created by tire NPS community, 
Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 
appointed — and published — scholar^ author. 

Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 



NAVAL 

POSTGRADUATE 

SCHOOL 

MONTEREY, CALIFORNIA 


THESIS 


ESTABLISHING A PRODUCT BASELINE FOR GLOBAL 
POSITIONING SYSTEM SATELLITES THROUGH 
FUNCTIONAL AND PHYSICAL CONFIGURATION AUDITS 

by 

Travis G. Willcox 
September 2011 

Thesis Advisor: Gary Langford 

Second Reader: Charles Pickar 


Approved for public release; distribution is unlimited 




THIS PAGE INTENTIONALLY LEFT BLANK 



REPORT DOCUMENTATION PAGE 


Form Approved OMB No. 0704-0188 
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing 
instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection 
of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including 
suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 
Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction 
( Project H (0704^0188)J/Vashington BB DC20503^_^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^_ 

I. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 

September 2011 Master’s Thesis 

4. TITLE AND SUBTITLE Establishing a Product Baseline for Global 5. FUNDING NUMBERS 

Positioning System Satellites through Functional and Physical Configuration 
Audits 

6. AUTHOR(S) Travis G. Willcox _ 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION 

Naval Postgraduate School REPORT NUMBER 

Monterey, CA 93943-5000 

9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING 
SMC AGENCY REPORT NUMBER 

El Segundo, CA 90245 

II. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government. IRB Protocol number N/A 

12a. DISTRIBUTION / AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE 

Approved for public release; distribution is unlimited A 

13. ABSTRACT (maximum 200 words) 

Programs without a proper technical baseline will not be able to achieve cost, schedule, and/or performance 
objectives. The purpose of this thesis is to provide clear steps, methods, guidelines, and suggestions to mature the 
functional, allocated, and product baselines from the development baseline to the contract baseline for the acquisition 
of a Global Positioning System (GPS) space segment. Implementation of these recommendations will reduce cost 
and/or schedule for programs such as GPS across the Space and Missile Systems Center (SMC). The thesis better 
defines, recommends updates, and suggests tailoring for relevant sections in standards such as MIL-STD-1521B and 
MIL-STD-973. It narrows some of the policies established in the DoD 5000.2 and other commonly used space 
acquisition regulations while satisfying the GPS Wing System Engineering Plan (SEP) requirement for the completion 
of a Functional and Physical Configuration Audit (FCA/PCA). It also identifies some characteristics of conducting 
appropriate and efficient audits for space segment acquisition programs in the GPS Wing that can be adapted and 
applied to similar programs across SMC. Ultimately, this thesis attempts to set the foundation for SMC and/or Wing 
level plans, policies, and instructions used to establish the product baseline for space systems acquired at SMC. 

14. SUBJECT TERMS Functional and Physical Configuration Audit FCA/PCA, Space 15. NUMBER OF 

Systems Acquisition Baseline, Technical Review, Technical Baseline, Product Baseline, PAGES 

Allocated Baseline, Configuration Baseline, System Verification Review _95_ 

16. PRICE CODE 


17. SECURITY 

18. SECURITY 

19. SECURITY 

20. LIMITATION OF 

CLASSIFICATION OF 

CLASSIFICATION OF THIS 

CLASSIFICATION OF 

ABSTRACT 

REPORT 

PAGE 

ABSTRACT 


Unclassified 

Unclassified 

Unclassified 

uu 


NSN 7540-01 -280-5500 Standard Form 298 (Rev. 8-98) 


Prescribed by ANSI Std. Z39.18 


I 




























THIS PAGE INTENTIONALLY LEFT BLANK 



Approved for public release; distribution is unlimited 


ESTABLISHING A PRODUCT BASELINE FOR GLOBAL POSITIONING 
SYSTEM SATELLITES THROUGH FUNCTIONAL AND PHYSICAL 
CONFIGURATION AUDITS 


Travis G. Willcox 
Captain, United States Air Force 
B.S., U.S. Air Force Academy, 2001 

Submitted in partial fulfillment of the 
requirements for the degree of 


MASTER OF SCIENCE IN SYSTEMS ENGINEERING MANAGEMENT 

from the 

NAVAL POSTGRADUATE SCHOOL 
September 2011 


Author: Travis G. Willcox 


Approved by: Gary Langford 

Thesis Advisor 


Charles Pickar, PhD 
Second Reader 


Cliff Whitcomb, PhD 

Chair, Department of Systems Engineering 



THIS PAGE INTENTIONALLY LEFT BLANK 


IV 



ABSTRACT 


Programs without a proper technical baseline will not be able to achieve cost, 
schedule, and/or performance objectives. The purpose of this thesis is to provide 
clear steps, methods, guidelines, and suggestions to mature the functional, 
allocated, and product baselines from the development baseline to the contract 
baseline for the acquisition of a Global Positioning System (GPS) space 
segment. Implementation of these recommendations will reduce cost and/or 
schedule for programs such as GPS across the Space and Missile Systems 
Center (SMC). The thesis better defines, recommends updates, and suggests 
tailoring for relevant sections in standards such as MIL-STD-1521B and MIL- 
STD-973. It narrows some of the policies established in the DoD 5000.2 and 
other commonly used space acquisition regulations while satisfying the GPS 
Wing System Engineering Plan (SEP) requirement for the completion of a 
Functional and Physical Configuration Audit (FCA/PCA). It also identifies some 
characteristics of conducting appropriate and efficient audits for space segment 
acquisition programs in the GPS Wing that can be adapted and applied to similar 
programs across SMC. Ultimately, this thesis attempts to set the foundation for 
SMC and/or Wing level plans, policies, and instructions used to establish the 
product baseline for space systems acquired at SMC. 
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I. INTRODUCTION 


A. BACKGROUND 

Systems can be defined as interoperating parts, pieces, components, 
subsystems, and/or segments with certain inputs, internal processes, and 
outputs intended to accomplish a given objective or set of objectives. To manage 
these independent entities as an operational system, it has become a common 
practice to identify requirements for each piece part based on the operating 
concept of the system and its overarching architectural framework. As these 
requirements are established at the highest level of the system and allocated 
down to the appropriate segments, subsystems, or components, it is a good 
practice to establish them as a requirement or technical baseline. When the 
respective aspects of the system are designed, a specification is typically 
authored to document how the item is to be built in a repeatable manner (i.e., 
production). With that in mind, a verification process should be used to make 
certain that the product has in fact been built to the specifications and/or 
functions as intended. To manage all the requirements, specifications, and 
processes, especially for a complex system of systems, it becomes necessary to 
manage these requirements, specifications, and resulting manufacturing and 
verification processes in terms of baselines and modifications in order to build 
and maintain a relevant operational system. 

Specifically, Global Positioning System (GPS) requirements begin with 
user, operator, and/or customer requirements that are defined in terms of Key 
Performance Parameters (KPPs) in the GPS Operational Requirements 
Document (ORD) or Capabilities Development Document (CDD). These 
parameters, along with those from the system interface requirements in the 
Interface Control Documents (ICDs), are interpreted, validated, and delineated 
through the Joint Capabilities Integration Development System (JCIDS) or Air 
Force Space Command (AFSPC) requirements process to be transferred to the 
GPS Wing system requirements management process to provide the functional 

1 



performance requirements for the system and dictate how it will interact with 
interfacing systems. This process (illustrated in Figure 1) produces internal ICDs 1 
for the interfaces of subsystems necessary to meet the higher-level 
requirements. 


JCIDS 

(Operational 

Definition 

Process) 

Defoes user /operational 
needs, cjpjb&tms 
repu^emens constants 
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Requirements 

Management 
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TecHnjcfl dazj end products as 
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Figure 1. GPS Requirements Development Process (From: GPSW, 2008) 


Once the user and operator requirements are identified, the GPS Wing 
uses three technical baselines to acquire, produce, and maintain GPS satellites, 
ground systems, and user equipment. According to the GPSW Systems 
Engineering Plan (SEP) of 22 September 2008 ((GPSW) 2008): 

The GPSW is a dynamic and multifaceted organization that is 
involved in sustaining, modernizing, developing, and managing the 
evolving GPS mission capabilities. The Wing’s number-one priority 
is to sustain current capabilities for military and civil users 
worldwide. The foundation of the SEIT operation is management of 
the integrated system baseline (technical performance, schedule, 
and cost) and its associated interfaces. The program’s chief 
priorities are to implement a low-risk schedule that sustains current 
system performance, meet phased performance requirements in an 


1 Interface Control Document (ICD), Capabilities Design Document (CDD), Capabilities 
Production Document (CPD), Department of Defense Air Force (DoDAF), Critical Operational 
Issues (COI), System Requirements Document (SRD), Technical Requirements Document 
(TRD), GPS Community of Interest (GPS COI), System Engineering and Integration Team (SEIT) 
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incremental fashion with time-certain delivery, provide system 
flexibility for future growth, and control total Government ownership 
costs. 

Further, the system’s operational baseline has been established 
starting with the initialization of the Block I system, and the 
sustainment and modernization is controlled through the 
management of this baseline. Subsequent improvements (Blocks II, 
MR, IIR-M, IIF, and III) are the result of new requirements and 
identification of operational deficiencies by the system’s users and 
operators. 2 Operator-identified deficiencies are corrected either by 
50th Space Wing maintenance actions or are identified to FIQ 
AFSPC [Fleadquarters Air Force Space Command] as needed 
capability improvements. A similar process exists at Warner Robins 
Air Logistics Center (WR-ALC) for the GPS UE [User Equipment]. 
These needs are documented as changes to the GPS CDDs 
[Capabilities Development Documents] and CONOPS [Concept of 
Operations] that are provided to SMC/GPSW [Space and Missile 
Systems Center/Global Positioning System Wing] to enable 
establishment of the next system Development Baseline. Because 
the 50 th Space Wing implements changes to the operating 
configuration, care must be taken to ensure that the new system 
Development Baseline is consistent with the actual operating 
configuration. GPSW then allocates the system-level requirements 
to the segment Contract Baselines for the IPTs’ (Integrated Product 
Team’s) acquisition of the segment products. The three technical 
baselines can be defined as (1) the operational baseline, which 
represents the currently fielded, operational system capability; (2) 
the development baseline, which represents the functional, 
allocated, and product baselines for the planned upgrade to the 
system capability; and (3) the contract baselines, which are the 
segment-allocated portions of the development baseline that are 
managed by the IPTs and are binding on the development 
contracts. 


2 The first GPS satellites developed in the 1970s were referred to as Block I. After 9 satellites 
were successfully launched to demonstrate the concept and capabilities, Block II was developed 
and 9 more satellites were launched in 1989 and 1990 to provide the Initial Operational Capability 
(IOC). The ensuing improvements were implemented in an incremental block fashion up to the 
most recently launched Block IIF with enhanced signal strength, additional civil signals and 
modernized capabilities. Block III is in the initial acquisition design stages to be launched as early 
as 2014 (Wikipedia, June 2011). 


3 




Figure 2. System Baseline Relationships (From: GPSW, 2008) 


AFSPC is ultimately the customer that represents the Global Positioning 
System Community of Interest (GPS COI), which includes all users but consists 
of representatives from different user groups such as the Federal Aviation 
Administration (FAA), and various commercial companies. The operators for the 
GPS System, namely the 50 th Space Wing, are shown in brighter yellow within as 
part of the Control Segment where a Material Control Board (MCB) is used to 
consider and make decisions on possible system modifications. For those items 
that are approved, an update is made to the Operational Baseline and passed to 
the Space Control User Equipment for any associated modifications as well as 
being passed through an operating configuration consistency check to become 
part of the next Functional Baseline that is to be acquired. The updates that 
cannot be made within the operator MCB Modification process are sent through 
the AFSPC requirements process to be refined and incorporated in the next 
possible functional baseline for acquisition by the GPSW. The GPSW uses the 
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Space System Acquisition process as specified by the System Engineering 
Integration and Test process identified in the GPSW SEP to result in the 
contracted procurement of the system by the Program Contracting division. 

B. GPS BASELINE COMPONENTS 

The Operational Baseline is the existing baseline that defines the 
previously acquired system that is currently in use, to include any modifications 
made by the operator through a MCB process. This baseline serves as the 
definition of the current system that provides for the legacy capabilities to be 
maintained and enhanced in an updated baseline through the acquisition process 
using the development baselines, namely the Functional, Allocated and Product 
Baselines. 

The Functional Baseline (FBL) is the system level architecture, design, 
and interface specifications that are in turn allocated to the segmented 
subsystems for implementation in block upgrades through the Allocated 
Baseline(s) (ABLs) resulting in the respective contract or product baselines. The 
Product Baseline (PBL) is the contract baseline formally established for 
production through the technical review process that culminates in the Functional 
Configuration and Physical Configuration Audits (FCA/PCA). 

The FBL consists of the specifications and documentation that describes 
the operational characteristics of the overall system and the architectural layout 
of the systems within the system, along with their associated design specification 
and interface control documentation. The Defense Acquisition Guidebook 
(Defense Acquisition University 2010) describes the FBL as follows: 

[The] Functional Baseline [is the] definition of the required system 
functionality describing functional and interface characteristics of 
the overall system, and the verification required to demonstrate the 
achievement of those specified functional characteristics. This 
baseline is derived from the Capability Development Document 
(CDD) and normally includes a detailed functional performance 
specification for the overall system and the tests necessary to verify 
and validate overall system performance. The functional baseline is 
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normally established and put under configuration control at the 
System Functional Review. It is usually verified with... a Functional 
Configuration Audit (FCA). 

The ABL is the documentation that describes the segments’ operational, 
interoperational, and interface requirements as allocated from the higher-level 
system requirements. The system level requirements are allocated to the 
individual programs along with interface requirements, design constraints, and 
the verification required qualifying the design and demonstrating the achievement 
of the specified characteristics for the associated segment. For programs like 
GPS, the system is divided into space, ground, and user equipment systems 
(collectively referred to as subsystems) with generational acquisition program 
blocks and their associated subsystems and components. According to the DAU 
Guidebook, the ABL defines: 

The configuration items making up a system, and then how system 
function and performance requirements are allocated across lower 
level configuration items (hence the term allocated baseline). It 
includes all functional and interface characteristics that are 
allocated from the top level system or higher-level configuration 
items, derived requirements, interface requirements with other 
configuration items, design constraints, and the verification required 
to demonstrate the traceability and achievement of specified 
functional, performance, and interface characteristics. The 
performance of each configuration item in the allocated baseline is 
described in its preliminary design specification as are the tests 
necessary to verify and validate configuration item performance. 

The allocated baseline is usually established and put under 
configuration control at each configuration item's (hardware and 
software) Preliminary Design Review (PDR), culminating in a 
system allocated baseline established at the system-level PDR. 

The final aspect of the Development Baseline, the Product Baseline or 
PBL, consists of all the documentation determined by the program Systems 
Engineering and Integration Team (SEIT) to describe sufficiently the physical and 
functional configuration of the end item as it is to be produced by the prime 
contractor. This may include documentation such as the design specifications or 
baseline, the As-Built Configuration Records (ABCRs), the requirements 
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verification process, any waivers or deviations on the vehicle functions or 
physical design, and the production process or build instructions. The design 
baseline is the documentation that defines the units, components and 
subsystems and how they are to be combined or integrated to meet the system 
or segment specifications. The ABCR is the documentation of the assembled 
hardware, the parts used, and the final configuration of how the space vehicle 
was actually built. The ABCR may differ slightly from vehicle to vehicle due to 
tolerances and acceptable variations in parts and material. 

The PBL also serves to identify which functional and physical 
characteristics are to be verified during acceptance testing for workmanship 
confirmation. These requirements are typically identified through a requirements 
verification matrix that delineates the method to be used for the verification of 
each requirement. Each segment must break the ABL down into applicable 
specifications while verifying that the higher-level requirements are provided for 
in the specifications at that level. This verification is accomplished through the 
contractor requirements management process and should be accomplished as 
early as possible to prevent the redesign of lower level subsystems/components 
or rewriting lower level specifications. However, when programs, such as GPS, 
use proto-qualification as a means of verifying, validating, and qualifying the 
design and requirements for the space segment, the technical risk of insufficient 
system performance must be mitigated through support from the configuration 
control process. That is, approval and validation of the specifications and 
requirements at each level is accomplished through the Configuration Control 
Board (CCB) prior to the verification testing for the first flight article, as opposed 
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to building an expensive and time-consuming vehicle solely for testing 3 . Either 
way, this qualification process is the formal process by which a manufacturer’s 
product is examined for compliance with the requirements of a source control 
drawing for the purpose of approving the manufacturer as a source of supply 
(Hagan 2009). This approval ensures that the design specifications meet the 
intent of the requirements and that the system is built and functions as designed. 
Accomplishing this early and in an iterative manner prevents late redesign work. 
Furthermore, a proto-qualification program allows the use of the initial flight 
article for physical testing to levels that ensure the system is robust without the 
potential impacts on longevity from the higher energy levels required for full 
qualification testing. 

Finally, the production process and build instructions cover those items 
that are needed to describe how to accomplish each task during the assembly of 
the vehicle. Altogether, the PBL should specify what the customer is purchasing; 
how it should be built; and the testing needed to verify the requirements were 
met—all that is needed to recreate the same vehicle without prior knowledge of 
the specific system or the assembly process itself. These items should be 
defined and submitted for approval in the Critical Design Review (CDR), 
however, the PBL may see changes as the design is actually implemented. Such 
changes are typically for practical reasons of adapting to either specific 
applications or as-built configurations and can be made through an approved 
configuration management process without formal customer approval as long as 
there are no impacts to form, fit, or function. If so, the change is considered a 


3 For the purpose of this thesis, validation refers to only that of the requirement 
specifications, not the validation of the actual system. Validation then is the process of ensuring 
that the lower level specifications and as designed systems fully provide for what was intended by 
the higher level specification (i.e., requirement traceability between specifications). Verification is 
the act of showing that is actually the case for the system hardware and software through test, 
demonstration or analysis. The GPSW SEP states, “4.2.1.1.2.3 Development Baseline 
Requirements Validation. The GPS SE&I contractor is responsible for continued analysis of the 
DOORS database and the development baseline to ensure that all directed and statutory 
requirements are captured along with their full traceability. This requirements traceability and any 
changes to it are controlled by the GPSW Requirements Working Group and are captured within 
the change control process for validation by the CCB.” 

8 



Class 1 change and requires an Engineering Change Proposal (ECP) to process 
the change through the government’s configuration management process. A key 
factor in reviewing these changes should be the determination whether they must 
be implemented in the current build, the next build, or only require documentation 
changes. Regardless, the documentation should be updated and revised 
accordingly to reflect the current configuration and document as a new baseline 
separate from previous versions or builds. 

The Defense Acquisition Guidebook’s (Defense Acquisition University, 
2010) defines the product baseline as follows: 

Documentation describing all of the necessary functional and 
physical characteristics of a configuration item; the selected 
functional and physical characteristics designated for production 
acceptance testing; and tests necessary for deployment/installation, 
operation, support, training, and disposal of the configuration item. 

The initial product baseline includes "build-to" specifications for 
hardware (product, process, material specifications, engineering 
drawings, and other related data) and software (software module 
design—"code-to" specifications). The Initial product baseline is 
usually established and put under configuration control at each 
configuration item's Critical Design Review (CDR), culminating in 
an initial system product baseline established at the system-level 
CDR. By DoD policy, the PM shall assume control over this initial 
product baseline after the system-level CDR and control all Class 1 
changes. Until completion of the System Verification Review (SVR) 
and/or FCA, Class 1 changes shall be those changes that affect the 
government performance specification. Following the SVR/FCA, the 
government will further define contractually what constitutes a 
Class 1 change. The system product baseline is finalized and 
validated at the Physical Configuration Audit. 

A well-defined development baseline (consisting of Functional, Allocated 
and Production Baselines, their equivalents, and/or the appropriate and approved 
waivers and deviations) documents what is planned and being accomplished, so 
it is critical for a design that provides a repeatable production and operational 
baseline for a space system that consistently meets the customer’s 
requirements. Without appropriate documentation, the configuration of the 
completed product may be unknown or inadequately replicated in production. To 
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accomplish a comprehensive review and to document changes through 
baselines, the GPSW SEP ((GPSW), 2008) states, “System/segment, prime item 
specifications, prime item fabrication, and critical items will be subject to 
configuration audits, namely the Functional Configuration Audit [FCA]/Physical 
Configuration Audit [PCA] to establish the product baseline. However, regarding 
the accomplishment of an FCA/PCA for individual programs the GPS Wing SEP 
((GPSW), 2008) states, “Any contract-specific guidance or expectations are 
program unique; details on this subject are provided in the appropriate program 
annex of this SEP.” This means each program must research, assess, 
determine, establish, write, and accomplish its own FCA/PCA process. In 
establishing the FCA/PCA process, a program office is required to follow the 
technical review guidelines provided in Department of Defense Instruction (DoDI) 
5000.02, December 2, 2008 (Under Secretary of Defense (Acquisition, 
Technology and Logistics) 2008). This instruction is further defined in 
documentation such as the Defense Acquisition University (DAU) Defense 
Acquisition Guidebook (Defense Acquisition University 2010), the Department of 
Defense Systems Engineering Plan Preparation Guide Version 2.01 April 2008 
(Office of the Deputy Under Secretary of Defense for Acquisition and Technology 
2008) and, previously, the National Security Space Acquisition Policy Number 
03-01 27 December 2004 (NSS 03-01). Although these documents provide 
policies and purposes, they do not establish lower level working guidelines and 
objectives for the execution of an FCA/PCA. Turning to Military Standards (MIL- 
STDs) 973 and 1521B on Configuration Management (CM) and Technical 
Reviews for Systems, Equipment and Software, one might hope to find a process 
for establishing a baseline, however, these standards do not provide any more 
than broad objectives and definitions. The general guidelines are insufficient for 
determining a process that will properly document the configuration. Instead, 
these documents do not provide specific tasks and instructions for accomplishing 
an FCA/PCA. 
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Generally, many standards are focused on programs of mass production 
with Low Rate Initial Production (LRIP) and subsequent Full Rate Production 
(FRP) phases. However, most space systems require relatively few space 
vehicles of the same design and architecture to populate a constellation and do 
not justify such an approach to production. Therefore, there are some common 
points in the MIL-STD Certification Sheets to tailor for space system acquisition 
programs. Tailoring the language in these certification sheets allows a Space 
System Acquisition Program to achieve the intent of the standard by making 
minor non-substantative revisions to the wording of the sheets for better 
application to the subject program. In the end, these sheets could be formalized 
as a MIL-STD Certification Sheet/appendix on their own for use in SMC space 
acquisition applications. See Appendix A (Global Positioning Systems Wing 
2009) for an example of tailored Certification Sheets for a GPS Space Segment. 

C. ASSUMPTIONS 

1. The culminating event in a technical review process used for 
establishing the development baseline for the acquisition of a GPS 
space segment block upgrade is referred to as an FCA/PCA. This 
thesis focuses on the acquisition process that provides a product 
baseline as part of the development baseline for the incremental 
upgrade of the GPS system that is purchased in blocks, or a 
number of satellites that provides for the capabilities and 
interoperation with the existing system while providing the desired 
upgrades or additional life for the system. 

2. Low quantity multi-vehicle programs. Although some of the existing 
guidance was written for higher volume production programs that 
often make use of LRIP and FRP phases, the process defined in 
this thesis provides the product baseline for satellite acquisition 
programs producing only enough satellites to populate an 
operational constellation or augment multiple aging satellites. 

3. Differences in the generations of a space segment, between 
programs and the means of satellite acquisition at SMC are slight 
enough to allow standardization in guidance at some level below 
that of the current/relevant DoDls, MIL-STDs and Aerospace 
Technical Operating Report (TOR). This allows for efficiency within 
a system program office, or equivalent, by providing a common 
process to be applied across multiple programs. 
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4. The contract(s) are set up in such a way to be able to consider the 
subcontracted products sufficiently audited to be included in a 
Prime Contractor’s design baseline, requiring limited government 
oversight. To be discussed in Section II. 

D. PURPOSE 

This thesis focuses on the development baseline as it is documented, 
managed, and verified to, ultimately, establish the satellites’ functional 
characteristics and physical configuration; delineate the system requirements; 
and establish the processes for development, testing, and requirements 
verification in the product baseline. 

The generic objectives provided by higher-level policies are specified here 
in greater detail providing a process to accomplish the FCA/PCA as the final step 
in the technical review process for Space Segment Acquisition Programs in the 
GPSW. This innovation will provide a standard method for establishing the most 
up to date technical/operational baseline and may also provide a basis for similar 
standards in other programs at SMC. However, the primary intent was to tie 
multiple policies and instructions together to provide a common application as a 
foundation for program level planning in the program SEP as required by DoDI 
5000.2: 

Technical reviews of program progress shall be event-driven and 
conducted when the system under development meets the review 
entrance criteria as documented in the SEP. They shall include 
participation by subject matter experts who are independent of the 
program (i.e., peer review), unless specifically waived by the SEP 
approval authority as documented in the SEP. (Under Secretary of 
Defense (Acquisition, Technology and Logistics)) 

The PM shall use a configuration management approach to 
establish and control product attributes and the product baseline 
across the total system life cycle. This approach shall identify, 
document, audit, and control the functional and physical 
characteristics of the system design; track any changes; provide an 
audit trail of Technical reviews of program design decisions and 
design modifications; and be integrated with the SEP and technical 
planning. 
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The following shows the final review and establishes the technical 
baseline in terms of the relevant product, contract, and operational baselines. 

E. RESEARCH QUESTIONS 

This thesis answers several questions. 

1. What are the necessary outputs of a technical review FCA/PCA? 

2. What means should be used for the culmination of a technical 
review for a GPS Space Segment Acquisition Block? 

3. What objectives and methods are appropriate for the government 
FCA/PCA process in order to establish the technical baseline for 
GPS and/or SMC space acquisition programs? 

4. Which strategies are most beneficial for system engineering in the 
production of GPS Space Vehicles? 

5. Flow can these objectives and methods be applied effectively for 
the acquisition of a GPS space segment? 

6. What role does configuration management play in the maintenance 
of a technical baseline for production purposes? 

F. BENEFITS OF STUDY 

This thesis provides guidelines for establishing the Product Baseline of a 
program through the final phase of a government audit/review process. Starting 
with the certifications found in the MIL-STDs, which are a means of documenting 
the objectives and their accomplishment to provide for the intended outcome of 
the FCA/PCA, this study suggests tailoring of the MIL-STD provisions as 
appropriate for GPS Satellite acquisition. Several tools are then recommended to 
improve the execution of the FCA/PCA and the baselining process. In summary, 
the recommendations include the following. 

1. Tailored certification sheets from MIL-STD-973 and/or MIL-STD- 
1521B to ensure that each area of the physical and functional 
configuration is properly addressed. 

2. Entrance/Exit Criteria to provide criterion for the initiation and 
completion for the FCA/PCA. 
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3. Recommended structure for the FCA/PCA process, including the 
review types and the intersections with other program products and 
processes. 

4. Recommendations for revisions to higher-level policies in 
accordance with (IAW) with the findings herein. 

G. SCOPE AND METHODOLOGY 

Beginning with the FCA/PCA definition found in the higher-level SMC 
policy (Aerospace) this thesis suggets a method by which a satellite design can 
be reviewed to establish a technical baseline for the production of a GPS space 
segment. The primary focus is on the culminating milestone of the technical 
review process known as the FCA/PCA, which is used to baseline the 
configuration documentation for programs in the GPSW at SMC. It points to 
acceptable processes, checklists, and certifications that can be used to approve 
the technical baseline resulting in the purchase of the final design by the 
government. The thesis incorporates aspects of existing guidelines and policies 
from DAU and the DoD (MIL-STD) to describe and recommend the products of 
an FCA/PCA. The thesis also provides suggestions on how to integrate these 
reference products with other tools frequently used in acquisition programs, such 
as risk management or the SEP. To do so, the following four steps were 
accomplished to understand common practices within the SMC/GPSW and 
provide the final products identified above. 

1. Conducted literature review of applicable guidelines/policies in 
multiple fields to understand what is currently being used in the 
field. 

2. Highlighted applicable AF and industry practices used in the design 
and technical baseline process for space system acquisitions. 

3. Analyzed previous guidelines and standards, positing new 
standards for reference in the System Engineering and FCA/PCA 
process. 

4. Developed recommendations for improving and standardizing the 
technical review and baselining process for the SMC and the 
GPSW. 
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II. THE FCA/PCA PROCESS 


A. INTRODUCTION 

The final milestone in the technical review process is, typically, a 
government audit, consisting primarily of the FCA/PCA, which is intended to 
support the acquisition life cycle by establishing an accurate product baseline 
that meets the user’s needs to define how each vehicle is to be built. Typically, 
the FCA/PCA is the culmination of the qualification program and/or the 
acquisition phase following the CDR, delineated in the NSS 03-01 (Figure 3), and 
provides for the Build Approval/Production Decision. However, the FCA/PCA 
may be combined with a Proto-Flight Qualification (Proto-Qual) Program to be 
completed simultaneously with the first production/proto-qual vehicle, as is 
common for many space system acquisition programs. In any case, it completes 
the government audit of and agreement to the qualification of the system design 
while establishing the PBL for all follow-on acceptance vehicles, unless otherwise 
stated. 
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Although the acquisition process seems to be in a constant state of 
revision, the process generally follows what was established in the National 
Space Strategy Acquisition Policy 03-01, depicted in Figure 3. The process starts 
with the Pre-Systems Acquisition phase and the identification of a user or 
operator need that is formally approved and requested by the Joint Requirements 
Oversight Council (JROC) through an Initial Capabilities Document (ICD). At the 
time of approval, a Concept Decision Meeting is held to kick-off the Concept 
Studies phase for the development and proposal of possible Concepts of 
Operation (CONOPs) intended to highlight the functional characteristics to best 
achieve the objectives of the system. The CONOPs are then complimented by 
the definition and characterization of their respective Architectures, and the 
system infrastructure envisioned to provide the functionality required. An Analysis 
of Alternatives is then accomplished to consider and report the pros and cons of 
each concept. During this formative period, the JROC ICD is further specified in a 
CDD. Meanwhile, the Test and Evaluation (T&E) Strategy and the Integration 
Plan are drafted to ultimately provide for the test, and verification of the system 
requirements and system integration. The Concept Studies phase culminates in 
a decision on whether to proceed into Phase A for the development of a 
proposed concept. 

In Phase A, a program develops the requirements and design for the 
formally conceptual system and reviews each in the System Requirements 
Review (SRR) and System Design Review (SDR). Additionally, the T&E Master 
Plan (TEMP) is developed based on the T&E strategy to document the process 
and requirements for verification and demonstration while the JROC CDD is 
updated with any changes necessary for the developing system. All of this 
development work is reviewed and considered for Phase B approval to proceed 
into the formal development of the system design. 
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Phase B consists of the preliminary design work to define the subsystems 
and interfaces to make up the system. It culminates in the aptly named 
Preliminary Design Review (PDR) and a decision to proceed into Phase C, along 
with an update to the JROC CDD and TEMP. 

In Phase C, the design is brought to completion and approved in the 
Critical Design Review (CDR). Coincidently, the JROC CDD is transitioned from 
a planning document into a Capabilities Production Document (CPD) that 
describes what will actually be built, as opposed to what is being planned. At this 
point, the TEMP is finalized and the JROC CPD supports a build decision to 
proceed into Phase D Build and Operations. 

The Build and Operations phase kicks-off the production of the first flight 
article, which can be used for full or “partial” proto-qualification testing, as defined 
in the glossary. A decision to buy follow on units is then made in conjunction with 
the final input from the FCA/PCA and the establishment of a production process 
or production line for to build the remaining articles to be purchased. If a proto¬ 
qualification program was used, the first article can be shipped and processed for 
the first launch followed by establishing the Initial Operational Capability (IOC) 
supported by a Post Deployment Review to determine whether a unit is in an 
acceptable operational condition and is able to be sustained and maintained. 
Once IOC is achieved, the sustainment phase begins for the operational units 
while production continues for any remaining units to be purchased and/or 
deployed. When all units required for Full Operational Capability (FOC) are 
deployed and considered operational, the FOC milestone can be declared 
complete, ending one acquisition cycle and starting the next for any subsequent 
upgrades. 

B. PURPOSE OF THE TECHNICAL REVIEW AND FCA/PCA PROCESSES 

The technical review process serves to mature a design and its supporting 
configuration documentation progressively, culminating in an FCA/PCA that 
provides the product baseline to be used as the contract baseline for production. 
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However, an FCA/PCA can take several forms that may be left to the discretion 
of the Program Manager (PM), the System Engineer (SE), and/or directed by 
higher-level policy. Depending on the scope and breadth of information and data 
to be reviewed for the program, the audit can be broken into incremental phases 
or completed as a single event, at the discrepancy of the PM and/or SE team(s). 
Whatever the case, the audit should incorporate information from the design and 
development, production and testing, systems engineering, integration, and 
program management aspects of the program. The primary intent is to review 
data from the Prime Contractor (PC). It is assumed all subcontractor and vendor 
products have been audited by the prime contractor to an acceptable level of 
scrutiny. Participation from the government, by invitation, is offered when 
possible and appropriate. Such participation by government is reasonable 
because it is a common practice that helps prevent government interference in 
subcontracts, holds the prime contractor accountable for their end product(s), 
limits the potential scope of the government audit. It is commonplace to include 
government participation by invitation in associated contract language. The 
units/components delivered to the PC will be considered baselined, at this 
associated level, as delivered and documented in the unit data package or 
equivalent prior to integration. Any changes after that, including the work to 
integrate the unit into the higher-level assembly, will be subject to government 
audit. Once the FCA/PCA is complete and the baseline established, the 
government will purchase the product as specified under contract and can take 
control of the final configuration and manage the baseline IAW the program 
contract and/or appropriate program directives/processes. 

The FCA/PCA should serve to validate the contractor’s production 
process. The audit should typically consist of a thorough inspection of the 
ABCRs; the seller’s design baseline; and the production process/build 
instructions. The ABCR should be compared to the As-Designed (AD) 
Configuration to ensure that the product meets the intended configuration 
managed design. Any design changes, whether Engineering Change Proposals 
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(ECPs), and Engineering Orders (EOs) that have been implemented since the 
previously established baseline should be reviewed for accuracy, completeness, 
appropriateness, and acceptability. Then in order to compare this design 
baseline to the ABCR, the work/build instructions used for the 
assembly/production of the product, along with Quality Assurance inspection 
documentation, should be evaluated to determine whether they have been 
implemented appropriately, IAW applicable guidelines and directives, to ensure a 
consistent and high quality final product. In short, a review of the design baseline, 
ABCR, and work instructions should provide confidence from all parties that the 
contractor can safely, efficiently, and appropriately plan and direct a repeatable 
and adequate production process to build the final product(s). 

The PCA portion of the audit for a space segment acquisition program 
should include a physical inspection of the final product that considers any 
potential cost impacts. This inspection will provide a verification that the 
assembly is built IAW the work instructions and procedures identified, which in¬ 
turn were reviewed in the ABCR to AD validation. Although, this review can be 
completed in several different ways, it is advantageous and efficient to leverage 
off the factory support provided by the Assembly, Integration, & Test (AI&T) team 
and Defense Contract Management Agency (DCMA) personnel who are involved 
in the day-to-day efforts. These support personnel can verify the build and 
installation real-time/in-process and document findings to provide for final AB 
verification without having to reaccess or reassess the hardware while 
consuming additional time and resources. The purpose of using the existing 
DCAM personnel is to prevent an added cost or resource need for the program 
while providing an independent review of the system/processes. 

The other facet of the review process, the FCA, is intended to conclude 
the qualification/proto-qualification test phase and approve the “kick-off” of the 
Acceptance Test Phase (ATP) for Validation and Verification (V&V) of the 
allocated and functional aspects of the development baseline. The FCA includes 
requirement and test program V&V. At the completion of the FCA, all 
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requirements should be verified or waived to show that the design can either 
meet the intended operational performance for the system or operate with a 
known, analyzed, and documented acceptable deficiency, respectively. Finally, if 
there are any non-conformances for either the physical or the functional 
configurations they must be formally approved via waiver or deviation IAW the 
program contract parameters and CM policies and processes, or otherwise 
remedied. The waivers and deviations should be summarized in the final 
report/documentation of the technical review. In the end, the review should also 
provide an overall impact assessment of the waivers and deviations, collectively. 
This is a consideration in the following section on risk assessment. 

C. ASSESSING RISKS TO PROCEED INTO PRODUCTION 

One of the ultimate goals for establishing a high fidelity technical baseline 
is to provide the necessary input for a reliable production process. Production 
includes all activities directly associated with the manufacturing and assembly of 
the completed space segment system. These activities include tooling, supply 
chain management, part and component kitting, sparing, constructing or building, 
and labor force management. These activities typically accomplished by the AI&T 
team provide the end item for an acquisition program. To replicate the product for 
a multi-vehicle space system, a consistent application of a well-defined technical 
baseline is necessary. As stated in the assumptions, GPS Space Segment block 
acquisitions are for a limited number of space vehicles that implies fewer spares, 
if any, and typically is well accommodated by a proto-qualification program that 
can make use of the qualification vehicle as an operational asset instead of 
building a fully capable asset solely for the purpose of testing at pre-defined 
higher standards that prevent the item from being used for operational purposes. 
However, because a design or engineered system is never without flaw, the 
technical review process should serve to assess the risk of proceeding into the 
production of the remaining vehicles, in addition to the objectives stated above. 
To assess this risk, the technical review team (typically consisting of the program 

SEIT, AI&T team, independent reviewers, or their equivalents) will leverage on 
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several existing efforts, products, and resources. One of which includes the 
existing program Risk Management (RM) process and the associated risk status 
as well as any kind of Mission Assurance Review (MAR) or similar assessment 
that has been accomplished. Combining these efforts with the technical 
assessment completed during the technical review, the team should consider the 
cost, schedule, and technical risk to the program if the vehicle system is to 
proceed into production. Although the technical review will often be focused on a 
technical risk assessment related to the capability of the system, as designed, to 
meet operational performance or the Technical Performance Measures (TPMs) 
at the End of Life (EOL), this review should also consider the cost and schedule 
impacts that may be experienced. The technical review may even incorporate 
business and schedule risk assessments as required by the program SEP or PM. 

As stated in the previous section, this technical assessment should 
include the cumulative impact of the deviations and waivers on the program. 
Once the margin available between the expected performance and the allocated 
requirement is determined, the SV program should complete an assessment of 
how the waived or deviated out-of-spec conditions, or non-conformances, 
cumulatively affect the expected EOL performance of the SV or system as a 
whole. With this analysis, a risk assessment can be completed to project the 
likelihood and consequences of failures associated with the out of spec 
conditions. 

Inherently, some risk will always be present in the operation of an SV, 
however any significant risk should be considered to determine whether it can be 
worked around, is acceptable for flight as is, or if it should be mitigated through 
appropriate means. This decision is ultimately up to the Flight Readiness 
authority, but should be considered and mitigated when and where possible by 
the PM, Integrated Product Team (IPT), and PC throughout the development 
effort. 
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D. CHAPTER SUMMARY 


The technical review and baselining process is the culmination of the 
design and development phase of the acquisition process. In the end, a product 
design and production process is not formally defined or qualified by the 
customer without the completion of an FCA/PCA, or a similar review. This review 
will produce a report, signed certifications, and the appropriate documentation to 
identify the product baseline as derived from the functional and allocated 
baseline. This product baseline is to be used for production and/or the 
acceptance testing on the program. If anything is lacking, it should be captured in 
liens, waivers, or deviations, as appropriate, and will be assessed for the risk to 
the program as it continues into production. The ultimate objective is to use the 
product baseline built on the allocated, functional, and existing operational 
baselines to provide an improved and upgraded system based on operational 
and user inputs, establishing a new operation baseline as shown in Figure 4. 


22 



Baselines 


Operational Baseline: 



Products as defined 
by contract 


Figure 4. Baseline Inputs and Outputs 


23 

































Beginning with the Operational Baseline consisting of the existing system 
design, architecture and operations, the JCIDS and the AFSPC work together, 
with inputs from the user and operations groups, to implement the requirements 
process in order to support the Chairman of the Joint Chiefs of Staff and the 
JROC in identifying, assessing, and prioritizing joint military capability needs as 
required by law. The capabilities are identified by analyzing what is required 
across all joint capability areas to accomplish the mission and codified in the 
CDD and ORD to capture the KPPs for the system. These documents feed the 
acquisition process to be broken down into SRDs, Technical Requirements 
Documents (TRDs), Specifications (Specs), Interface Control Documents (ICDs) 
and Technical Standards that are matured through each aspect of the 
Development Baseline and, finally, approved through the FCA/PCA for purchase 
through the Contract Baseline. 
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III. INTEGRATING COMMON PROGRAM PRODUCTS/TOOLS 

A. INTRODUCTION 

Many commonly used program tools can, or even should, be used in the 
FCA/PCA process. Some of these tools are useful for completing the audit(s), 
while others provide appropriate input or an interface to the program execution 
process. Some common program tools are described and suggested for use 
here. 

B. SCHEDULING 

The FCA/PCA for a program should be integrated into the program 
schedule and updated on a regular basis along with other program activities and 
milestones. However, a more detailed schedule of FCA/PCA activities may be 
appropriate and can be accomplished through the standard program scheduling 
team and tools. The FCA/PCA should qualify the AI&T process leading into 
production and can therefore validate the program schedule. If problems are 
identified, experienced, or noted, the baseline schedule and associated durations 
should be adjusted appropriately. Any specific occurrences should be 
documented as FCA/PCA Action Items. 

C. CERTIFICATION SHEETS 

Certification Sheets are intended to formally document the completion of 
certain critical activities in the FCA/PCA with an agreement and signature on 
what was accomplished related to the primary objectives of the event. An 
example of suggested content is provided in Appendix I of MIL-STD-1521B (DoD 
1996) and MIL-STD-973 (DoD 1992); however, these requirements are contract 
or program dependent and the signature pages can be tailored as appropriate for 
the using program. MIL-STD-973 states, “This standard is applicable only to the 
extent specified in the tasking directive or contract Statement of Work (SOW). 
Contracts invoking this standard will specifically identify the appropriate 
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applicable paragraphs and Appendices, or portions thereof, in the tasking 
directive or—contract SOW. (See 6.2 for specific tailoring guidance.) The 
selection of necessary configuration management requirements from this 
standard to be applied to a specific program will be tailored to suit the life cycle 
phase, complexity, size, intended use (including joint and combined 
interoperability), mission criticality, and logistics support of the CIS.” Once agreed 
to by the authoritative parties, and specified in the contract, the team can work to 
accomplish Certification Sheets for each applicable increment of the FCA/PCA. 
Appendix A of this thesis provides the MIL-STD Certification Sheets and 
suggested redlines that can be further refined based on the needs of the specific 
block, program, and contract. 

D. TEST PROGRAM 

The test program is a critical component of the FCA/PCA. The FCA/PCA 
is in fact not only meant to use the test program to verify requirements but is 
meant to actually validate and approve the test program while serving as a 
procedure review and, ultimately, a record of the requirement verification 
accomplished by the testing. Although verification can be achieved by 
demonstration or analysis, IAW the Requirements Verification Matrix, or 
equivalent, for a given requirements document, testing often provides for a 
majority of the verification, if possible, and is usually the most reliable method. 

With this in mind, the FCA/PCA can leverage off the test program to 
accomplish a portion of the effort in conjunction with the Run for Record(s) 
(RFRs) of each test phase. The test program should include a review process for 
pre- and post-test activities related to test preparation and data review. This 
process is further delineated in the Aerospace Technical Operating Report, TOR- 
2007(8583)-6414 Volume 1 (Aerospace 2009); however, it is mentioned here as 
it feeds into the FCA/PCA. Test Readiness Reviews (TRRs) should be used to 
ensure that the testing is to be completed using the flight hardware, software, 
and test equipment configuration(s) needed in order to sell-off the RFR and 
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associated system requirements, as well as verify functionality and performance 
of the Space Vehicle (SV). Once the entrance criteria have been met, the TRR 
can be held. When all exit criteria for the TRR are completed, the review can be 
closed, approving the stated configuration and sequence of testing used to 
accomplish the test objectives (e.g., requirement verification). This means that a 
Test Compliance Matrix (TCM), or equivalent, has been compiled to identify 
which requirements are to be verified using specified test data. Then, after the 
test setup is complete, consent to test can be given and the test can commence. 
After the testing is complete and it is determined that the data is sufficient, 
meaning no retest is necessary for compliance purposes or troubleshooting and 
the current test configuration is no longer needed, a Consent to Break (CTB) 
configuration must be provided by the appropriate authorities. Next, a Post Test 
Review (PTR) should be accomplished to assess relevance and allocation of the 
data obtained and close out the test phase. Finally, a RFR meeting, or event, can 
be held to tie all the test data and FCA/PCA objectives together to provide for the 
related increment of the audit and functional performance verification. 

Additionally, MIL-STD-1521B requires a review of the test procedures and 
results, including but not limited to all “test procedures and interface documents” 
as well as “All test data sheets... to assure that the test was witnessed by a 
representative of the Contracting Agency” IAW FCA Certification Sheets (Cert 
Sheets) 1 and 2, as tailored in Appendix A. Additionally, PCA CS 4, requires a 
review of “the acceptance test results... to ensure that testing is adequate, 
properly done, and certified” (USAF). To accomplish this review, a program 
should provide an SV representative to team with and/or be supported by a 
DCMA counterpart to witness and/or review the test data as close to real-time as 
possible. The initial review, to ascertain whether all necessary information is 
properly recorded based on the plan approved via the TRR, should be completed 
before a CTB configuration is provided. This verification is necessary in order to 
prevent a retest if a test objective was not appropriately provided for. The SV rep 
can then prepare a full test report to address the successes and shortcomings of 


27 



the test, to include any anomalies or failures requiring a waiver or change in 
script, process or configuration. This planning and review process should also 
identify the subset of tests to be run as part of the acceptance test phase for 
production vehicles after the qualification phase, to be agreed to and validated 
IAW the FCA/PCA Cert Sheets. 

E. ACTION ITEMS AND MEETING MINUTES 

In order to document the activities and accomplishments, minutes should 
be taken and recorded during the FCA/PCA event(s). Additionally, in order to 
ensure completeness, action items should be captured to identify and track any 
follow-on tasks necessary to close each event. These should be classified for 
level of severity to show criticality based on time required and/or technical 
impact. Category I is typically defined as those items that impact the technical 
baseline, impact one or more of the FCA/PCA objectives, are a constraint to 
“closing” the event, or should be “closed” within a designated timeframe. 
Category II is typically something that does not affect the purpose of the event or 
can be “closed” outside of the restricted timeframe specified for Category I Action 
Items. Finally, category III can be used to identify something that does not affect 
the event or program schedule, is to be completed by another party, and/or does 
not need to be completed near term. 

F. CONFIGURATION MANAGEMENT 

Using the FCA/PCA process, CM plays a critical role in establishing and 
maintaining the technical baseline for a program. Pg 78 of DoDI 5000.2 dated 08 
December 08 states: 

The PM shall use a configuration management approach to 
establish and control product attributes and the technical baseline 
across the total system life cycle. This approach shall identify, 
document, audit, and control the functional and physical 
characteristics of the system design; track any changes; provide an 
audit trail of Technical reviews of program progress shall be event- 
driven and conducted when the system under development meets 
the review entrance criteria as documented in the SEP. They shall 
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include participation by subject matter experts who are independent 

of the program (i.e., peer review), unless specifically waived by the 

SEP approval authority as documented in the SEP. 

CM tracks the design approved at the CDR and documents any approved 
changes in the AD Configuration. The prime contractor then provides the AB 
configuration records, a list that should be reflected in the completed 
manufacturing documents, and FCA/PCA serves to confirm the AD against the 
AB configuration. CM is crucial for providing both the incoming and outgoing 
documentation for each, ultimately resulting in the Technical Baseline (TBL) 
documentation. In some cases, CM, as a branch of the SEIT organization, may 
be responsible for completing the FCA/PCA. 

In order to complete the audit process, the CM manages all proposed 
baseline changes from their submittal/documentation to approval/disapproval, 
and ultimately, their implementation or dismissal. Using such practices as version 
control, search and correlation schemes, concurrency, provenance, isolation, 
redundancy, and mapping, the baseline products can be planned, 
communicated, controlled, directed, organized and consensus driven. These 
products include: 

1. Stakeholder requirements (including the system boundaries, the 
scope of activities, the objectives, and the relevance) 

2. Set of technologies, their means, and implications 

3. System functions, processes, performances, behaviors, results, 
and losses 

4. Risks associated with each requirement 

a. Individual 

b. Cumulative 

5. Style, manner, and methodologies used to identify and correct 
problems, and make decisions 

6. Engineering and multi-disciplinary practices that are acceptable 

7. Compilation of information according to various conditions 
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a. Current 

b. Anticipated 

c. Range 

8. Baseline schedule, cost, and forecast, and 

9. Policy, regulations, rules, guidance documents. 

CM best practices should be used. These include implementation of a 
CCB process, authoring and complying with a CM plan, but is ultimately to be 
applied IAW the relevant guidance and regulations of the governing 
organization(s). For GPS satellite design and manufacture, that would be the 
GPSW and the affiliated contract company(ies). Once the baseline is established 
and documented, the relevant program can take possession of and control that 
baseline IAW the contractual specifications and agreements in place. 

G. PERSONNEL 

The audit is ultimately the responsibility of the Configuration Management 
and SEIT team(s). So being, personnel are provided primarily by those teams. 
However, this team should be augmented as appropriate by DCMA, test team 
personnel, PM personnel, and any other outside support required. DCMA is 
responsible for the independent review and support of certain defense contracts. 
Because GPS programs typically meet the criteria for DCMA oversight, it is 
valuable to leverage the relationship to take advantage of their expertise, prevent 
duplication of effort, prevent unnecessary expenses and for the added value of 
an independent review. 

While the FCA/PCA can be used to validate the manufacturing and 
assembly process, it should also validate the technician and engineering support 
used for production. This can be done as part of the AB/AD configuration review 
but ultimately serves to approve the process and manning necessary for SV 
production by providing data on the associated processes and their timelines. 
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H. RISK MANAGEMENT 


Although Risk Management (RM) is an independent program activity, it is 
also a primary objective of the Technical Review process and, therefore, the 
FCA/PCA. This is to say the FCA/PCA should help provide for risk identification 
and risk mitigation as it serves to assess the technical, physical, and strategic 
shortcomings of a design and production process while providing a forum for 
such concerns to be acted on and addressed in a timely manner. 

Risks to and risks identified in the FCA/PCA should be captured and 
managed appropriately IAW the local RM processes. Risks to the of the 
FCA/PCA event itself can be initiated and managed as a program risk and can 
be worked by the responsible party, the SEIT team, or a working group. Risks to 
hardware or production identified in the FCA/PCA event itself should be 
documented in the minutes and action item-tracking log as necessary. The team 
can then work to accomplish the mitigating activities as described for action 
items. However, existing RM processes and tools should be used to manage the 
actual risk as it affects the program. 

I. CHAPTER SUMMARY 

Each program may have different variations or implementations of the 
tools mentioned here; however, this thesis is intended to provide a guideline for 
the application of those tools and processes in order to accomplish the 
associated objectives of the Technical Review process in an efficient manner. 
Scheduling is fundamental to any program and its significant events and 
milestones. Being one of those milestones, FCA/PCA is no different and should 
be actively monitored and managed in the program schedule. Funding 
management, configuration management, personnel management, risk 
management, and action item tracking are critical components of program 
management as well and help to accomplish the workload. One of the critical 
processes is the test program and requirements verification effort. Like any other 
significant program activity, all of the tools available can be used to aid in the 
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completion of the test program for the purpose of verifying the functionality and 
performance of the product in regard to the respective requirements. Meanwhile, 
Certification Sheets are not commonly used in other applications but are 
prescribed for the FCA/PCA in the Mil-Std guidelines. These certification sheets 
along with all the other management tools should be well used to complete a 
successful FCA/PCA and establish a technical baseline. 


32 



IV. APPLICATION OF STUDY: EXECUTION OF A GPS SPACE 
SEGMENT FCA/PCA AND BEYOND 

A. INTRODUCTION 

FCA/PCA is a critical event for most DoD production programs, however 
each program is unique in its application of the audit process to varying degrees. 
Therefore, each program should plan for its completion sufficiently in advance. 
Once the FCA/PCA has been completed there are several implementations that 
allow for speedier completion of the remainder of the satellites. The necessary 
parts and material should be purchased and readily available in the appropriate 
queue; the production process for these satellites will have been refined, 
optimized and approved; and as long as each of the following satellites are built 
to the FCA/PCA approved product baseline, they do not have to undergo any 
more testing than a subset of the qualification tests known as acceptance tests 
and finally be approved by the program Engineering Review Board (ERB) for the 
verification of workmanship proficiency. These efficiencies pertain primarily to 
GPS, which requires at least 24 satellites to populate the Medium Earth Orbit 
constellation at about 22,000 km above the earth, but is relevant for any number 
of multiple satellite programs. 

B. STRATEGY 

In order to complete an FCA/PCA, a program must map out an 
appropriate execution strategy that includes Entry and Exit (E/E) criteria, a 
timeline that coincides with respective program accomplishments, logistical 
planning, personnel provisions, coordination with invested parties and a 
determination on whether there will be one culminating event/audit, two separate 
audits or multiple incremental audits. Such a strategy requires an agreement 
between all parties involved, namely the contractor and the customer. 
Coordination with DCMA is necessary and is a criteria for accomplishment. If it is 
not previously stipulated in the contract, these parties must also agree on the 
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implementation of the audit process (i.e., whether the FCA/PCA will be 
accomplished in increments or as a single event, how the team member roles 
and responsibilities will be determined, what the guiding policies and procedures 
will be, and what the E/E criteria will be). Each of these components of the audit 
process helps determine the execution strategy. Usually the implementation 
strategy is determined based on the size and complexity of a program, the depth 
of the team(s) experience and personnel availability, and the timeline available 
for accomplishment. For example, delivering three satellites with 3,529 functions 
within five years results in 445 configuration items that need to be tracked and 
managed. A formal, written audit plan and procedure is mandatory to prevent 
unexpected cost impacts and schedule delays. 

GPS space system acquisition is typically on a large enough scale, in 
terms of cost and complexity, that an incremental approach to the completion of 
the FCA/PCA is warranted. In fact, the incremental approach is recommended for 
most programs. This approach allows the program to schedule their reviews over 
a period in order to spread the effort out into manageable tasks and review 
sections or segments of the program. These incremental reviews should be 
accomplished, ideally on a frequent basis, once the established criteria are met 
for the completion of different components, subsystems, tests, or as other 
significant accomplishments related to the PBL are achieved. Audits of this 
nature also provide for real-time or near real-time review of data while allowing 
for updates with any significant change as necessary, reducing the risk and 
duration of program delays in the case of anomalies or discrepancies. At the very 
least, reviewing the data in the integration and test process flow is convenient, 
efficient and even essential, for the V&V of the requirements and qualification 
program: consisting of test, analysis, and demonstration. To accomplish the 
FCA/PCA during the execution of the test program, the objective of each specific 
test phase must be well understood and stated. The requirements to be verified 
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should be documented in order to determine whether sufficient data is provided 
from the testing. With this planning in place the FCA/PCA can be an efficient and 
effective tool to transition from the design and development. 

C. RESULTS 

Having completed the Test program and V&V process through the 
FCA/PCA, the program can approve the acceptance program for the remaining 
articles to be produced outside of the qualification program. Having qualified the 
manufacturing procedures, tooling, personnel and resources the FCA/PCA 
should provide for a streamlined production process. It also serves to validate the 
design for the entire fleet to allow the ATP to be applied to the remainder of the 
fleet to simply verify workmanship, as opposed to workmanship and design 
performance that were verified in the qualification vehicle. 

D. BASELINE CHANGES AND CONFIGURATION CONTROL 

As satellites are produced, there may be some necessary modifications or 
changes that need to be applied to the baseline due to unforeseen source 
changes, facility changes, design or process improvements, or changes in 
constraints (e.g., schedule, cost, policy, or skill set). It is the program’s 
responsibility to determine which entity(ies) is(are) responsible for the design and 
configuration control prior to FCA/PCA. Because of their knowledge, experience, 
and investment in the documentation and the deliverable product, it is reasonable 
and essential to identify the designer or owner of the relevant specification level 
for that responsibility. It is then necessary to identify who is responsible for 
configuration control as well as how much and what kind of customer oversight is 
required post FCA/PCA. If the contractor is responsible for the design and 
production of the satellite(s), the responsibility of configuration control could well 
reside with them until the design is validated through FCA/PCA. The contract 
may specify the transfer of ownership at that time; however, the customer may 
decide to leave the CM function with the contractor. 
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E. CHAPTER SUMMARY 

Configuration items developed at the government’s expense require an 
FCA/PCA prior to acceptance of the item. These guidelines and principles will 
serve to improve efficiency and provide a structure for the execution thereof in 
the GPSW as well as any other adoptive agency at SMC and beyond. To 
provide formal documentation of this process, a sufficiently well defined and 
documented plan is necessary. With an adequate plan in place, the process will 
carry the program through the V&V phase to establish a baseline for the 
acceptance testing or full rate production phase. Through that transition, the 
continued configuration management function/responsibility remains a crucial 
role to be coordinated by the customer with the contractor as appropriate. 
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V. CONCLUSIONS 


A. KEY POINTS AND RECOMMENDATIONS 

It is in the best interest of all stakeholders to determine early what is 
expected in and from the FCA/PCA for a program. Such planning provides key 
insight into what needs to be accomplished when in order to make the necessary 
preparations. Planning for such things as a proto-qualification program that 
combines qualification testing, requirements verification and data to support the 
completion of the FCA, is a complicated enterprise. It is also difficult to plan 
resources, activities, tasks and schedules that are dependent on other 
independent activities and processes. To assist in the process, the following is a 
list of recommended items that should be specified and documented early: 

1. FCA/PCA E/E Criteria 

2. Configuration control plan for pre and post FCA/PCA 

3. Acceptance versus Qualification verification requirements 

4. Program specific tailoring of MIL-STD 1521B Certification Sheets 

The final step, or purpose, of an FCA/PCA is to provide for the review, 

inspection, certification and documentation for the customer’s purchase of the 
design and, in the case that the proto-qualification process is used, the first 
production article. This entails the use of a Department of Defense Form 250 
(DD-250) to document the transfer of ownership for the subject property to the 
government. For GPS, and other satellite programs, this receipt for the hardware 
will be provided at the shipping dock, or at the time of shipment, as an Initial DD- 
250 IAW the relevant contract. The space vehicle can then be transferred by the 
government itself or a hand receipt, Department of Defense Form 1149 (DD- 
1149), can be written to allow temporary control by another entity for the purpose 
of shipment. Finally, IAW the contract language, the respective portion of the 
satellite system can be purchased with the Final DD-250 once the system has 
been launched, checked out and handed over to the government for control in 
flight. 
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B. RESEARCH CONCLUSIONS 


To answer the questions initiating this research: 

1. What are the necessary outputs of a technical review FCA/PCA? 

a. Product baseline to be used as the contract baseline for 
production 

b. Validation of the contractor’s production process 

c. Assessment of risk to proceed into production of the 
remaining units 

d. Physical inspection of the qualification or proto-qualification 
unit to ensure that the product is built IAW the work 
instructions and procedures identified 

e. Validation of the As Built Configuration Record (ABCR) to 
the As Designed (AD) baseline 

f. Conclusion of the qualification or proto-qualification test 
phase and approval for the “kick-off” of the Acceptance Test 
Phase (ATP) for Validation and Verification (V&V) of the 
workmanship of the products and the allocated and 
functional aspects of the development baseline 

2. What means should be used for the culmination of a technical 

review for a GPS Space Segment Acquisition Block? 

a. Coordination between appropriate parties (i.e., DCMA, prime 
contractor, program personnel, etc.) for the completion of the 
necessary audits, inspections, etc. 

b. Ensure closure of established entry and exit criteria 

c. Documentation and signatures in the certification sheets 
found in MIL-STD-973 and tailored in Appendix A 

d. Agreed to and documented configuration control of the 
production articles 

3. What objectives and methods are appropriate for the government 

FCA/PCA process in order to establish the technical baseline for 

GPS and/or SMC space acquisition programs? 

a. Test program validation 

b. Proto-qualification or qualification of the technical baseline 
and space vehicle hardware, design and functionality 

c. Incremental audits/reviews and physical inspections 
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4. Which strategies are most beneficial for system engineering in the 
production of GPS Space Vehicles? 

Due to the size, value and complexity, among other factors, the 
following aspects are the most beneficial and even critical methods 
for establishing the technical baseline for GPS and similar satellite 
acquisition programs. 

a. Proto-qualification 

b. An incremental review and physical inspection 

5. How can these objectives and methods be applied effectively for 
the acquisition of a GPS space segment? 

Through the following disciplines/tools: 

a. Schedule Management 

b. Funding management 

c. Configuration management 

d. Personnel management 

e. Risk management 

f. Action item tracking 

g. Certification Sheets 

6. What role does configuration management play in the maintenance 
of a technical baseline for production purposes? 

CM plays a critical role in establishing and maintaining the technical 
baseline for a program. Pg 78 of DoDI 5000.2 dated 08 Dec 08 
states: 

The PM shall use a configuration management approach to 
establish and control product attributes and the technical baseline 
across the total system life cycle. This approach shall identify, 
document, audit, and control the functional and physical 
characteristics of the system design; track any changes; provide an 
audit trail of Technical reviews of program progress shall be event- 
driven and conducted when the system under development meets 
the review entrance criteria as documented in the SEP. 

C. AREAS FOR FURTHER RESEARCH 

A valuable area for expansion of this thesis would be to include the other 
milestones within the overall Technical Review process. This would include lower 
level direction for the completion of specific events such as SRR, SDR, PDR, and 
CDR. 
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With GPS as an example of space vehicle design, development and 
production, the methods and principals described here can be tailored, 
expanded, and directly applied to the acquisition of similar systems. After making 
a determination regarding the extent of applicability to any unique program, these 
guidelines could at least serve as a foundation to establish further guidelines and 
policies. 

D. SUMMARY 

The FCA/PCA and related milestones are a critical piece of DoD 
production & acquisition programs. General guidance seems to be readily 
available; however, it is crucial that each unique program establish the standards 
of application to provide for a smooth and complete process. The suggestions 
presented here serve as an example, or potentially as a foundation for, what is 
needed at the center, system, and program levels to efficiently and effectively 
establish a proper technical baseline for a space systems acquisition program. 

Without these procedures and documentation, a program is less likely to 
succeed, if not actually unable to maintain its initial schedule, meet its prescribed 
system requirements, or remain within budget. It is recommended that the Space 
and Missiles System Center consider the potential benefits outlined here for 
adopting some principles of baselining procedural issues, and revised 
documentation standards in order to provide for the standardization of replicated 
processes at the detailed levels of SV production. An efficacious technical 
baseline can be established more efficiently to provide for a repeatable 
production process that will produce a system that meets the specified 
requirements in a more timely manner at a more predictable cost. 
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APPENDIX A. TAILORED FUNCTIONAL CONFIGURATION AUDIT 
(FCA) AND PHYSICAL CONFIGURATION AUDIT (PCA) 
CHECKLISTS AND CERTIFICATION SHEETS ORIGINATING 

FROM MIL-STD 973 


FCA Checklist 


Contract:_Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

CONTRACTOR REQUIREMENTS YES NO 

1. Verification Test Procedures Submitted _ _ 

2. Waiver/Deviation List Prepared _ _ 

3. Verification Testing Completed _ _ 

4. Verification Test Results Compiled & Available _ _ 

5. FCA Facilities Available _ _ 

6. Verification Test Procedures Reviewed and _ _ 

Approved 

7. Verification Testing Witnessed _ _ 

8. Verification Test Data and Results Reviewed _ _ 

Approved 

COMMENTS: 
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Final FCA CERTIFICATION SHEET NO. 1 

TEST PROCEDURES AND RESULTS 


Contract:_Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Verification Test Procedures and Results. The verification test/analysis 
results have been reviewed to ensure that testing is adequate, properly done and 
certified. (All test procedures and interface documents shall be reviewed to 
assure that the documents have been approved by the Government. All test data 
sheets shall be reviewed to assure that the test was witnessed by a 
representative of the Government). Caveat: The Government does not always 
have approval authority on the Test Procedures. In which case, the Mil-STD-973 
FCA Cert Sheet #1 can be tailored to: The verification test/analysis results have 
been reviewed to ensure that testing is adequate, properly done and certified. All 
test procedures and interface documents have been reviewed to assure that 
planned testing and test flow has been reviewed by the Government to ensure 
they meet with Government Approval. 

Open Actions: 

NONE 

Attach e d i s a li st of th e docum e nts r e v ie w e d. 

Documents reviewed: 


Check One 


□ 

□ 


Procedures and results reviewed satisfy the requirements and are 
accepted. 

See Attachment for comments. 


Attached is a list of deficiencies. 


Signature(s) of FCA/PCA Team Member(s) 
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Company/Function - Name 

Signature 

DATE 

(Contractor) SV SE Lead 

Name 



(Contractor) Quality Assurance Lead 

Name 



(Contractor) Configuration/Data Mgt Name 



USAF, GPSW, Block # Lead 

Name 




FCA L I ST OF DOCUMENTS REV I EWE D 


CONF I GURAT I ON I TEM NOMENCLATURE: 


DOCUMENT 

CONTROL 

NUMBER 

DESCRIPTION 

REMARKS 
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FCA CERTIFICATION SHEET NO. 2 

DEVIATIONS/WAIVERS 


Contract:_ Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Review of Deviations/Waivers. A review of all deviations/waivers to military 
specifications and standards that have been approved. The purpose is to 
determine the extent to which the equipment-(s}/computer software undergoing 
FCA vary from on e app li cat i on vary from on e applicable specifications and 
standards and to form a basis for satisfactory compliance with these 
specifications and standards. In accordance with this paragraph, all applicable 
deviations/waivers have been reviewed with the following results: 

Open Actions: 


Documents Reviewed: 

Request for Deviations and Waivers (RDW) Master Log 
RDW System Assessment 
Nonconformity Processing 

Check One 

| | The equipment(s)/computer software listed on Certification Sheet 
No. 1 of this report complies with contract requirements. See 
attachm e nt - for comm e nts . 


□ 


Attached is a summary of FCA d i scr e panc ie s list of deficiencies. 


Signature(s) of FCA Team Member(s) 
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Company/Function - Name 

Signature 

DATE 

(Contractor) SV SE Lead 

Name 



(Contractor) Quality Assurance Lead 

Name 



(Contractor) Configuration/Data Mgt Name 



USAF, GPSW, Block # Lead 

Name 




A. Deviation/Waiver Review Team Instructions. All approved waivers and 
deviations to contract requirements shall be reviewed and recorded. Also, record 
any part of the FCA that fails to meet specifications or standards but is not an 
approved waiver/ deviation. 

B. Results of Team Review. List the deviations/waivers against the 
equipment/ computer software being FCA’d that were reviewed. 

FCA WA I VERS/DEV I AT I ON S 


CONF I GURAT I ON I TEM NOMENCLATURE: 


DOCUMENT 

NUMBER, 

TITLE 

REFERENCE 

(Spec, STD, 

Eter) 

CCB OR 

MRB 

APPROVAL/ 

DIRECTIVE 

REQUIREMENT 

WAIVED 

REMARKS 







45 


































Space Vehicle Deviations and Waivers 


*Note - the same list of deviations and waivers are listed on FCA Cert Sheet #2 

and PCA Cert Sheet #6 


ID 

Classification 

RDW Title 

Status 

DSP#### 

Minor 


Released 
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PCA CHECKLIST 


Contract: _Date: _ 

Contractor: _ 

Nomenclature:_ 

Cl Identifier:_ 

The following hardware, computer software, documentation shall be available for 
audit: 

YES NO 

1. Approved final draft of the Configuration Item Product specification _ 

2. A list delineating both approved and outstanding changes against the Cl _ 

3. Complete shortage list _ 

4. Acceptance test procedures and associated test results _ 

5. Engineering drawings with outstanding changes _ 

6. Operating, maintenance and illustrated parts breakdown manuals _ 

7. List of approved material review actions _ 

8. List of approved and/or pending waivers/deviations _ 

9. Approved nomenclature and nameplate _ 

10. Manuscript copy of all software Cl manuals _ 

11. Computer software version description documents _ 

12. Current set of listings and updated design descriptions or other means of 

design portrayal for each software Cl _ 

13. FCA minutes for each Cl _ 

14. Program parts selection list (PPSL) _ 

15. Final configuration verification report “as-designed/as-built” _ 

16. Completed hardware representing various stages of manufacture _ 

COMMENTS:_ 
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PCA CERTIFICATION SHEET 1 
For Equipment / Computer Software 


Contract: _Date: _ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Product Baseline. The following documents of the issue and date shown 
comprise the product baseline for the listed equipments /-computer software. 

Open Action Items: 

NONE 

Documents Reviewed: 

SS09-0048 Rev - Space Vehicle Technical Baseline Guide and Listing 
SS09-0085 Rev - Space Vehicle 1 As-Built Configuration Record Gate 13 
(See PIMS record A009876 for working copy) 

The following plan is to be accomplished post SV ship to validate the launch 
configuration of the vehicle. 

1. Vehicle is configured for launch at the Eastern Launch Site (ELS) 

2. Boeing Launch IPT Lead will provide as-built data to reflect the final 
launch configuration 

3. Boeing CM Lead will update the ABCR reflecting the launch configuration 

4. Government CM Lead will review the ABCR and document findings as 
appropriate 

- ASSEMBLY TOP - EQU I PMENT / COMPUTER 

SPEC NO . — DRAW I NG NO , - I SSUE - SOFTWARE 

NOMENCLAT URE 


Attach e d i s a li st of th e docum e nts r e v ie w e d 

Signature(s) of PCA Team Member(s) 
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Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block # 

Lead 

Name 
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PCA CERTIFICATION SHEET 2 
(For Equipment/ Computer Software) 


Contract:_Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Specification Review and Validation. SV Specification has been reviewed and 
validated to assure that they adequately define the configuration item and the 
necessary testing, mobility/transportability and packaging requirements. *Note: 
All requirement verification documents used to verify launch vehicles only include 
verification information for Delta. The program may use an alternate Launch 
Vehicle, Atlas, at a later Space Vehicle. Additional requirement verification 
documents will be addressed as appropriate when specific launch vehicles are 
selected. 

Open Actions: 

Documents reviewed: 


Specification Review and Validation Instructions: 

The detailed specifications listed in table 1 shall be reviewed for compliance with 
the applicable requirements. Each specification shall serve as the basic 
document for configuration control of the subject configuration items. The 
information contained within the specifications shall be audited at the PCA. 

1. Specifications Reviewed and Validated 


Control Number 

Description 

Revision 








2. Test Requirements Documents* (TRDs) Reviewed 


TRD 

Sequence 

Title 

Revision 









*Note: Test Requ 

rements Documents are not part of the Space Vehicle 


Technical Baseline Listing. 


50 




























Check One 

□ 

□ 


The Product Specifications are complete and adequately define the configuration 
item. They shall, therefore, constitute the product baseline. 

The Product Specifications are unacceptable. S ee attachm e nt 
for a li st of d i scr e panc ie s . 


Signature(s) of PCA Team Member(s) 


Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block # 

Lead 

Name 




- Sp e c i f i cat i on R e v ie w and Va li dat i on I nstruct i ons. -The— d e ta ile d 

sp e c i f i cat i ons li st e d i n paragraph — B. b el ow sha ll b e r e v ie w e d for 

comp li anc e w i th th e app li cab le r e qu i r e m e nts. — Each sp e c i f i cat i on sha ll 

s e rv e as th e bas i c docum e nt for conf i gurat i on contro l of th e subj e ct 

conf i gurat i on i t e ms. — Th e i nformat i on conta i n e d w i th i n th e sp e c i f i cat i ons 

sha ll b e aud i t e d at th e PCA. 

- R e v ie w and Va li dat i on R e su l t s 


1. Sp e c i f i cat i ons r e v ie w e d and va li dat e d: 

- EQU I PMENT/COMPUTER 

SPEC NO. PART NO. —PATE- SOFTWARE NOMENCLAT URE 


(s ee attach e d) 
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- 2. Sp e c i f i cat i ons R e v ie w e d and D i sapprov e d: 

- (Prov i d e attachm e nt for caus e s.) 

PCA L I ST OF SPEC I F I CAT I ONS REV I EWED 

CONF I GURAT I ON -ITEM- NOMENCLATURE: 


SPECIFICATION 

NUMBER 

PART 

NUMBER 

DATE/ 
REV. NO. 

EQUIPMENT/COMPUTER 

SOFTWARE 

NOMENCLATURE 
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PCA CERTIFICATION SHEET 3 

Equipment 


Contract:_ Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Drawing Review. Drawings have been compared with the equipment to ensure 
that the latest drawing change letter has been incorporated into the equipment, 
that part numbers agree with the drawings, and that the drawings are complete 
and accurately describe the equipment. 

Open Actions: 

None 

Documents Reviewed: 

SS02-0015 Parts, Materials and Processes Selection List (ADP 153) 
Government Physical Configuration Verification Report 
All items listed in Table below 
Check One 

The drawings are complete and accurately describe the equipment. 
HWCI/engineering drawing package; parts approved and listed on PMPSL 
I I Attached is a list of deficiencies 

Drawing Review Results 

The following drawings were reviewed by the Customer PCA sub-team: 


Part Number 

Nomenclature 

Revision 

CEO 










Attach e d i s a li st of th e docum e nts r e v ie w e d 

Check One 


— = j - Th e draw i ngs — ar e comp le t e and — accurat el y d e scr i b e th e 

e qu i pm e nt. 


Parts 


Th e draw i ngs ar e compat i b le w i th th e app li cab le contract Program 

S ele ct i on L i st (PPSL). 
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HWC I / e ng i n ee r i ng draw i ng packag e ; parts approv e d and li st e d on 


— = | - Attachm e nt i s a li st of d i scr e panc ie s. — R e f e r e nc e act i on 

i t e ms. 

Signature (s) of PCA Team Member (s) 


Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block # 

Lead 

Name 




A-. - Draw i ng R e v ie w R e su l ts. Th e fo ll ow i ng draw i ngs w e r e r e v ie w e d by th e 

PCA draw i ng r e v ie w sub - t e ams: 

(s ee n e xt pag e ) 
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PCA L I ST OF DRAW I NGS REV I EWED 


CONF I GURAT I ON -ITEM- NOMENCLATURE: 


DRAWING NUMBER 

AND REVISION 

NOMENCLATURE 

REMARKS 
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PCA CERTIFICATION SHEET 4 

(Equipment) 


Contract:_Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Acceptance Test Procedures and Results. The acceptance test procedures 
have been reviewed for adequacy and the acceptance test results have been 
reviewed to ensure that the testing has been properly done and certified. 

Attachm e nt _ i s a li st of th e docum e nts r e v ie w e d. 

Check One 

| | Proc e dur e s and r e su l ts r e v ie w e d sat i sfy th e r e qu i r e m e nts and ar e 
acc e pt e d. 


Attachm e nt i s a li st of d i scr e panc ie s. — R e f e r e nc e act i on i t e ms. 


Open Actions: 

NONE 

Documents Reviewed: 

DOP and GOP revision and review date can be found in SS09-0047. 


Procedure # 

Document Nomenclature 






Check One 

Kl The Acceptance Test Procedures have been reviewed and they satisfy 
the requirements and are accepted. 

Attached is a list of discrepancies. 


Acceptance Test Procedures : The following acceptance test procedures were 
reviewed and deemed adequate. 


Document 

Number 

Description 

Revision 

Date 
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Signature(s) of FCA/PCA Team Member(s) 


Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block # 

Lead 

Name 




- Acc e ptanc e T e st Proc e dur e s. Th e fo ll ow i ng acc e ptanc e t e st proc e dur e s 

w e r e r e v ie w e d by th e ATP Sub - T e am: 

- DOCUMENT - DATE/REV LTR DOCUMENT T I TLE - STATUS 

- NUMBER 


- Acc e ptanc e T e st R e su l ts. Th e fo ll ow i ng acc e ptanc e t e st r e su l ts 

docum e ntat i on w e r e r e v ie w e d by th e ATP Sub - T e am: 

- DOCUMENT - DATE/REV LTR DOCUMENT T I TLE - STATUS 

- NUMBER 


57 












































PCA CERTIFICATION SHEET 5 
(For Equipment/Computer Software) 


Contract:_ Date: _ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

Review of Shortages and Unincorporated Design Changes. The shortages 
and Unincorporated design changes listed on the proposed DD Form 250 
“Mat e r i a l I nsp e ct i on and R e c ei v i ng R e port” hav e b ee n r e v ie w e d. Wide Area 
Work Flow (WAWF, electronic DD Form 250, "Material Inspection and Receiving 
Report"), and other records have been reviewed. 

Shortages and Unincorporated Design Changes are described here and are captured in the Wide 
Area Work Flow (WAWF, electronic DD 250). Each are categorized as follows: 

1. SV Ship - Shipment of Space Vehicle to Launch Site 

2. SV Launch - Activities at launch site up to consent to launch 

3. Sustainment - Activities on-orbit 

4. None - Document updates or hardware Fly-As-ls dispositions 

Open Actions: 

See Attachment A 

Documents Reviewed: 

Gate 13 Lien Summary 

Attachments: 

Shortages and Unincorporated Design Changes 
Gate Closure Summary 

Check One 


Th e r e ar e no shortag e s or Un i ncorporat e d d e s i gn chang e s. 


Attachm e nt i s a li st of shortag e s and/or Un i ncorporat e d 

d e s i gn chang e s, and th e r e comm e nd e d corr e ct i v e act i on r e qu i r e d. 

R e f e r e nc e act i on i t e ms. 
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Check all that apply: 


A list of shortages are captured in Attachment A 

A list of Unincorporated Design Changes and the recommended 
corrective action is captured in Attachment A 

There are no shortages, unincorporated design changes, Unaccomplished 
tasks/open issues, or specified discrepancies 

S i gnatur e (s) of PCA T e am M e mb e r (s) 


Signature(s) of FCA/PCA Team Member(s) 


Conrmanv/Function - 

Sianature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block ## 

Lead 

Name 




A. Review of Shortages and Unincorporated Design Changes. All shortages 
and Unincorporated design changes listed on the proposed Wide Area 
Work Flow (WAWF, electronic DD Form 250 “Material Inspection and 
Receiving Report”), shall be reviewed by the Government or their 
designated representatives for a determination of what changes should be 
accomplished in the field and what changes should be accomplished at 
the contractor’s facility. The r e v ie w t e am Government shall also determine 
if the reported shortages and Unincorporated changes are complete. 


59 




























B. Results. Attachment A Llists the shortages and Unincorporated design 
changes that were reviewed in compliance with requirements, including 
the agreed-to corrective action. 
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PC A Certification Sheet #5 
Attachment A 


Definitions from MIL-HDBK-61A 

■ Shortage 

• Known deficiencies (e.g., requirement partially implemented) on 
the system 

■ Unincorporated Design Change 

• A change to the current approved configuration documentation 
of a configuration item that was not incorporated 

• Any alteration to a product or its released configuration 
documentation that was not incorporated. 


Unique 

Identifie 

r 

Ite 

m 

Tracking 

Mechanis 

m 

Typ 

e 

Descriptio 

n 

Comment 

s 

Effectivit 

y 

Ris 

k 

Constrain 

t 
















All 

Low 

None 
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PCA CERTIFICATION SHEET 6 
(For Equipment/Computer Software) 


Contract:_Date: 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 


Review of Deviation/Waivers: A review of all deviations/waivers to military 
specifications, standards and contract requirements that have been approved. 
The purpose is to determine the extent to which the equipment-(s}/computer 
software undergoing PCA vary from on e app li cat i on vary from on e applicable 
specifications and standards and to form a basis for satisfactory compliance with 
these specifications and standards. In accordance with this paragraph, all 
applicable deviations/waivers have been reviewed with the following results: 

Open Actions: 

WBP0299 Receive Customer Approval 

Documents Reviewed: 

PIMS Record A011679 RDW Master Log 

PIMS Record A014953 RDW System Assessment 

SIS-PRO-6655 Nonconformity Processing 

Check One 


□ 

□ 


The equipment(s)/computer software listed on Certification Sheet 
No. 1 of this report complies with all applicable specifications and 
standards. 

Attachm e nt Attached is a list of discrepancies and/or 
comments. 


Signature(s) of FCA/PCA Team Member(s) 
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Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block ## 

Lead 

Name 




Deviation/Waiver Review Team Instructions. All approved waivers and 
deviations to contract requirements shall be reviewed and recorded. Also, record 
any part of the PCA which fails to meet specifications or standards but is not an 
approved waiver/deviation. 

Results of Team Review. List the deviations/waivers against the 
equipment/computer software being PCA’d that were reviewed. 

PCA WAIVERS/DEVIATIONS 


CONFIGURATION ITEM NOMENCLATURE: 


DOCUMENT 

CONTROL 

NUMBER 

REFERENCE 
(Spec, STD, 
Etc.) 

CCB OR 
MRB 

APPROVAL/ 

DIRECTIVE 

REQUIREMENT 

WAIVED 

REMARKS 
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PCA CERTIFICATION SHEET 7 
(For Equipment/Computer Software) 


Contract:_Date: 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 


Exam i nat i on of th e Propos e d DP Form 250. Th e DP Form 250 has b ee n 

e xam i n e d to e nsur e that i t ad e quat el y d e f i n e s th e e qu i pm e nt/comput e r softwar e 

and that unaccomp li sh e d tasks ar e i d e nt i f ie d as d e f i c ie nc ie s. 

Review of Contractor’s Engineering Release and Change Control System. 

The contractor’s engineering release system and change control procedures 
have been reviewed to ensure that they are adequate to properly control the 
processing and formal release of engineering changes. 

Open Actions: 


Documents Reviewed: 


Check One 




The contractor's engineering release system and change control 
procedures are 

adequate for the processing and formal release of engineering changes. 


Q Attached is a list of deficiencies. 


Signature(s) of FCA/PCA Team Member(s) 
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Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block ## 

Lead 

Name 
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PCA CERTIFICATION SHEET 8 

(Equipment) 


Contract:_Date: 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 


Review of Logistics Support Plan for Pre-operational Support. The Logistics 
Support Plan for Pre-operational Support has been reviewed to ensure that it is 
adequate to support the acquisition phase and is compatible with the operational 
phase maintenance concept and support requirements. 

Check One 


□ 


, □ 
items. 


The contractor’s Logistic Plan for pre-operational support will fulfill 
the acquisition phase requirements and is compatible with 
operational phase needs. 

Attachm e nt i s a li st of d e f i c ie nc ie s . Reference action 


2. Review of Long Lead Time Items and Provisioned Items Processed Prior to 

PCA. Long Lead-Time items released, and items provisioned, prior to PCA have 
been reviewed to ensure that obsolete items resulting from pre-PCA design 
changes are purged from the system. Where basic items may be upgraded by 
rework or modification these actions have been verified as accomplished or in 
process based upon design change notice. 

Check One 


□ 


, □ 
items. 


Long lead time items and provisioned items processed, prior to PCA, are all of 
current configuration at time of PCA or are in work. 

Attachment_is a list of deficiencies. Reference action 


Signature(s) of FCA/PCA Team Member(s) 
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Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 



(Contractor) 
Configuration/Data Mgt 



USAF, GPSW, Block ## 

Lead 

Name 




PHYSICAL CONFIGURATION AUDIT 

Certification Sheet #9 


Contract:_Date:_ 

Contractor:_ 

Nomenclature:_ 

Cl Identifier:_ 

1. Review of Integrated Support Plan (ISP) for Pre-operational Support. The 

Integrated Support Plan (ISP) for Pre-operational Support has been reviewed to 
ensure that it is adequate to support the acquisition phase and is compatible with 
the operational phase maintenance concept and support requirements. 

Check One 




The contractor's ISP for pre-operational support will fulfill the acquisition 
phase requirements and is compatible with 

operational phase needs. 


Attached is a list of deficiencies. 


2. Production Process, Long Lead Items and Obsolete/Spare Parts are 

properly Addressed and Accounted for. Long lead time items released, and 
items provisioned, prior to PCA have been reviewed to ensure that obsolete 
items resulting from pre-PCA design changes are purged from the system. 
Where basic items may be upgraded by rework or modification these actions 
have been verified as accomplished or in process based upon design change 
notice. 


67 



















1. Long lead time items and provisioned items processed, prior to PCA, are all 
of current configuration at time of PCA or are in work. Any items removed 
from the design have been removed from the engineering Bill of Material and 
purged from the system if necessary. 

2. All engineering for rework/modification of SV1 items is verified as released in 
the system or are in process based upon design notice and work is complete. 


3. Production line parts acquisition and sparing strategy for SV1 has been 
reviewed to ensure production readiness, including proper handling / 
accounting of critical items in accordance with applicable requirements. 


Long lead time items and provisioned items processed, prior to PCA, are 
all of current configuration at time of PCA or are in work. 


Critical Items Handling Plan reviewed and found to be adequate with the 
following exceptions: ASD and CES loss of paperwork from storage facility 
in Seal Beach; high bay loss power, so loss environmental control. 


Open Actions: 

None 


Documents Reviewed: 


Document Number 

Revision 

Title 








Signature(s) of FCA/PCA Team Member(s) 


Company/Function - 
Name 

Signature 

DATE 

(Contractor) SV SE Lead 
Name 



(Contractor) Quality 
Assurance Lead 

Name 



(Contractor) 
Configuration/Data Mgt 
Name 



USAF, GPSW, Block ## 
Lead 

Name 
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APPENDIX B. GLOSSARY 


Acceptance Test Phase (ATP): Portion of a program after the design has been 
qualified by the qualification testing and FCA/PCA. Acceptance Testing verifies 
that each end item meets the performance specifications/requirements. 

Acceptance Vehicles: Space vehicles produced during the Acceptance Test 
Phase. 

Allocated Baseline (ABL): The initially approved documentation describing an 
item’s functional, interoperability, and interface characteristics that are allocated 
from those of a system or a higher-level configuration item; interface 
requirements with interfacing configuration items; additional design constraints, 
and the verification required to demonstrate the achievement of those specified 
characteristics. 

Allocated Configuration Documentation (ACD): The approved allocated 
baseline (ABL) and approved changes. 

As Built Configuration Record (ABCR): All documentation necessary to detail 
the final product configuration typically provided for each vehicle. The record 
includes such things as the Bill of Materials (BOM) line item/level, part number, 
nomenclature, reference designator, quantity, and serial number of each part 
along with the as-designed/as-built information 

As Designed (AD) Configuration Record: The configuration baseline 
documentation that specifies how each end item should be built (i.e., without any 
waivers or deviations that may exist for an individual unit or group of units). 

Assembly, Integration, & Test (AI&T): The entity responsible for, location for or 
function of manufacturing, producing, and testing production units. 

Baseline: Agreed-upon budget, manning, technical, and milestone requirements 
between the cognizant parties or appropriate authority. 

Build Approval/Production Decision: Decision made by the Milestone 
Decision Authority (MDA) to allow a program to commence with production. 

Capability Development Document (CDD): A document that captures the 
information necessary to develop a proposed program(s), normally using an 
evolutionary acquisition (EA) strategy. The CDD outlines an affordable increment 
of militarily useful, logistically supportable, and technically mature capability. The 
CDD may define multiple increments if there is sufficient definition of the 
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performance attributes key performance parameters (KPPs), key system 
attributes (KSAs), and other attributes) to allow approval of multiple increments. 
The CDD supports a Milestone B decision review (Hagan, 2009). 

Capability Production Document (CPD): A document that addresses the 
production elements specific to a single increment of an acquisition program. The 
CPD defines an increment of militarily useful, logistically supportable, and 
technically mature capability that is ready for a production decision. The CPD 
must be validated and approved prior to a Milestone C decision review (Hagan, 
2009). 

Configuration Baseline (CBL): Configuration documentation formally 
designated by the Government at a specific time during a Configuration Item’s 
(Cl’s) life cycle. Configuration baselines, plus approved changes from those 
baselines, constitute the current approved configuration documentation. There 
are three formally designated configuration baselines in the life cycle of a Cl, 
namely the functional, allocated, and product baselines. 

Configuration Control Board (CCB): Panel responsible for defining and 
managing the technical baseline of an end item. 

Configuration Management (CM): The technical and administrative direction 
and surveillance actions taken to identify and document the functional and 
physical characteristics of a configuration item (Cl), to control changes to a Cl 
and its characteristics, and to record and report change processing and 
implementation status. It provides a complete audit trail of decisions and design 
modifications. 

Consent to Break Configuration (CTB): The decision provided by the 
designated authority to change the test. 

Contract Baseline: Documentation, specifications, drawings, requirements that 
define what is to be completed by the prime contractor in terms of integrated and 
tested end item hardware. 

Critical Design Review (CDR): A multidisciplinary technical review, conducted 
for each configuration item when detailed design is essentially complete, with the 
objective of ensuring that the detailed design of the configuration item or system 
under review can proceed into fabrication, system integration, demonstration, 
and test, and can meet the stated performance and engineering specialty 
requirements of the configuration item (Cl) development specifications within cost 
(program budget), schedule (program schedule), risk, and other system 
constraints. 

Defense Contract Management Agency (DCMA): Department of Defense 
(DoD) component that works directly with Defense suppliers to help ensure that 
DoD, Federal, and allied government supplies and services are delivered as 
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close to contractual requirements as possible. DCMA typically provides contract 
and technical experts to provide for quality assurance oversight of a DoD 
program. 

Deviation: A specific written authorization granted prior to the manufacture of an 
item, to depart from a particular requirement or procedure for a specific number 
of units or a specified period of time. 

End of Life (EOL): The projected timeframe in which a system/unit is expected 
or the point in time when a system/unit actually starts performing below minimum 
requirement(s) due to design, component or hardware degradation from the 
operational environment, conditions, or use. 

Engineering Change Proposal (ECP): MIL-STD-973 document requesting a 
form, fit or function change to the design. The system or segment specification 
establishes the functional baseline. 

Engineering Review Board (ERB): The sub-panel, typically chaired by the 
lead/chief engineer, that pre-reviews/approves items for technical adequacy as 
designated/delegated by the program authority. 

Functional Baseline (FBL): The approved documentation describing a system’s 
or item’s functional, interoperability, and interface characteristics and the 
verification required to demonstrate the achievement of those specified 
characteristics. 

Functional Configuration Documentation (FCD): The approved functional 
baseline (FBL) plus approved changes. 

Global Positioning System (GPS): System of satellites, ground control and 
user components that operate to provide precision navigation and timing signals 
primarily for navigation data. 

Initial Operational Capability (IOC): In general, attained when some units 
and/or organizations in the force structure scheduled to receive a system have 
received it and have the ability to employ and maintain it. The specifics for any 
particular system IOC are defined in that system’s Capability Development 
Document (CDD) and Capability Production Document (CPD) (Hagan, 2009). 

Key Performance Parameters (KPPs): Those attributes or characteristics of a 
system that are considered critical or essential to the development of an effective 
military capability and that make a significant contribution to the characteristics of 
the future joint force. A KPP normally has a threshold representing the minimum 
acceptable value achievable at low-to-moderate risk, and an objective, 
representing the desired operational goal but at higher risk in cost, schedule, and 
performance. KPPs are contained in the Capability Development Document 
(CDD) and the Capability Production Document (CPD) and are included verbatim 
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in the Acquisition Program Baseline (APB). Certain KPPs may be mandatory or 
selectively applied, depending on the system. See Acquisition Program Baseline 
(APB), Validation Authority, Capability Development Document (CDD), Capability 
Production Document (CPD), Mandatory Key Performance Parameters (KPPs), 
Selectively Applied Key Performance Parameters (KPPs), Threshold Value, 
Objective Value, and Joint Potential Designator (JPD) (Hagan, 2009). 

Mission Assurance Review (MAR): An engineering assessment completed by 
a group independent of the design, production and operation of a system to 
critique potential weaknesses in any aspect that would unacceptably limit, 
degrade or jeopardize performance, primarily with respect to End of Life 
requirements. 

Post-Deployment Review (PDR): Conducted by DoD components beginning at 
Initial Operational Capability (IOC) and then nominally every 3 to 5 years or when 
precipitated by changes in requirements/design or performance problems. These 
periodic assessments verify whether the fielded system continues to meet or 
exceed thresholds and objectives for cost, performance, and support parameters 
approved at the full-rate production (FRP) decision. In addition to comparing 
actual versus expected levels of performance and support, at minimum the 
reviews should include Product Support Integrator/Product Support Provider’s 
performance, including effectiveness of sustained materiel readiness 
implementation, product improvements incorporated, and configuration control 
(Defense Acquisition University, 2010). 

Post Test Review (PTR): Assessment completed by the test engineering team 
and others, as designated, to determine the adequacy of the testing and review 
the data for trending and data analysis as required by the program system 
engineering authorities. 

Preliminary Design Review (PDR): A review conducted on each configuration 
item to evaluate the progress, technical adequacy, and risk resolution of the 
selected design approach; to determine its compatibility with performance and 
engineering requirements of the development specification; and to establish the 
existence and compatibility of the physical and functional interfaces among the 
item and other items of equipment, facilities, computer programs, and personnel. 
Normally conducted during the early part of the System Development and 
Demonstration (SDD) Phase. 

Product Baseline (PBL): The approved documentation describing all of the 
necessary functional and physical characteristics of the configuration item and 
the selected functional and physical characteristics designated for production 
acceptance testing and tests necessary for support of the configuration item. 

Product Configuration Documentation (PCD): The approved product baseline 
(PBL) plus approved changes. 
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Proto-Flight Qualification (Proto Qual) Program: The process of qualifying a 
design by testing a fully operational end item to a specified level that will 
adequately determine the performance characteristics, considering end of life 
conditions, but will leave enough performance margin to allow the unit to be used 
in an operational capacity, unlike a full qualification program in which a fully 
operational end item is tested to maximum performance levels, even to failure in 
some cases, to determine its operational bounds. 

Qualification Program or Qualification Testing: The determination of whether 
a unit built to a specified design is capable of meeting the system requirements 
through the end of its life, with a predetermined safety factor, in the relevant 
operational environments. 

Run for Record (RFR): The testing and data documented as the officially 
completed test required for verification of performance and/or production in 
accordance with the test compliance matrix and the qualification or acceptance 
testing plan. 

Space Vehicle (SV): The end item production product for a space program, 
typically in the form of a satellite. 

System Baseline: technical performance, schedule, and cost baselines. 

System Verification Review (SVR): The SVR is a multidisciplinary technical 
review conducted to ensure that the system under review can proceed into low- 
rate initial production (LRIP) and/or full-rate production (FRP) within cost 
(program budget), schedule (program schedule), risk, and other system 
constraints. 

Technical Baseline (TBL): Configuration documentation that identifies and 
defines the item’s functional characteristics (i.e., specifications, interface 
documents, and architectural views). 

Technical Performance Measure (TPM): Describes all the activities undertaken 
by the Government to obtain design status beyond that treating schedule and 
cost. A TPM manager is defined as the product design assessment, which 
estimates through tests, the values of essential performance parameters of the 
current design of work breakdown structure (WBS) product elements. It forecasts 
the values to be achieved through the planned technical program effort, 
measures differences between achieved values and those allocated to the 
product element by the system engineering process, and determines the impact 
of these differences on system effectiveness. 

Test Compliance Matrix (TCM): The designation of specific tests to be used to 
verify each requirement or group of requirements. 
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Verification and Validation (V&V): Validation is the process of confirming that 
the higher-level specifications or requirements are fully provided for and 
traceable to the product requirements. Verification is the task of ensuring that the 
product indeed satisfies those requirements in the end item. 

Waiver: A written authorization to accept an item for use “as is” after it has been 
found to depart from specified requirements. 
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